OpenEdge Getting Started:<br />Core Business Services Controlling the user ID and login sessions in audit data records

As described in the "Configuring additional user authentication systems and domains" section and in Chapter 4, "Identity Management," there is more than one way to architect a 4GL application's security system to authenticate and authorize application/database access, which supports non-repudiation of the user ID recorded in auditing events. You might want to use a single user ID for the application and all database connections, or you might want to use different user IDs for the application and each database connection. Another option is to use a combination of the previous two. For this reason, a 4GL application must be able to configure auditing to use the user ID set in the database connection or obtain it from an application-level authentication operation.

Both the existing, pre-Release 10.1A model of user authentication through SETUSERID( ) and the new OpenEdge Release 10.1A model using the CLIENT-PRINCIPAL object are supported. The general rule, however, is that you employ only one of the models in an application.

When using the existing model, your application is required to connect to an OpenEdge database using either the -U and -P options or a blank user ID connection, and then call the SETUSERID( ) function. Either way, your application is required to populate and use the user accounts provided by the OpenEdge database's _User table. With regard to auditing, the database connection's user ID is recorded in auditing records and the user authentication-system domain is always OpenEdge.

The CLIENT-PRINCIPAL model gives the application much more flexibility, but may require some additional configuration work at the production site by the database administrator. Using this model requires the following steps:

Coding the 4GL user authentication system that will generate the CLIENT-PRINCIPAL objects into the application.

Configuring the Trusted Domain Registry records in the OpenEdge database or databases.

Configuring the user authentication database options to set the authentication trust relationships:

The database connection requires that a user ID (CLIENT-PRINCIPAL) be validated against the database's Trusted Domain Registry.

The database connection will trust a user ID (CLIENT-PRINCIPAL) that has been validated by the application's Trusted Domain Registry.

Coding the 4GL application's initialization and use of an application-level Trusted Domain Registry:

Loading the Trusted Domain Registry from a specific OpenEdge database's tables.

Loading the Trusted Domain Registry from an external, 4GL-brokered source.

Coding the 4GL application points where a user ID must be set:

Using the SECURITY-POLICY:SET-CLIENT( ) method to validate and set an application-wide user ID, including all database connections.

Using the SET-DB-CLIENT function to explicitly validate and set a user ID for a specific OpenEdge database connection. (Each OpenEdge database connection must be set individually.)

Whether the application uses a single user ID (CLIENT-PRINCIPAL) for the entire application or multiple user IDs is totally at the discretion of the application designer. The one rule in the is that the SET-DB-CLIENT( ) function supersedes any user ID set using the SECURITY-POLICY:SET-CLIENT( ) method. For additional details about how to set this up in an application, see OpenEdge Development: Programming Interfaces .

The Audit Policy allows the audit administrator to select whether an authentication audit event will record just the simple user authentication operation or add the additional user login-session information about the user authentication system that was used.

The recorded user ID in the auditing records can come from either the PROGRESS session for those applications that provide their own user authentication and authorization or the OpenEdge database connection for those applications that use OpenEdge user authentication and authorization. You control where the user ID comes from through configuration options contained in the OpenEdge database and which control that database's policy. When the database option Use Application User Id for Auditing is not selected (which is the default), the user ID recorded in auditing records is set through one of the following three methods:

The OpenEdge database connection -U option.

The 4GL language's SETUSERID( ) function.

The 4GL language’s SET-DB-CLIENT( ) function, which requires a CLIENT-PRINCIPAL object.

When the Use Application User Id for Auditing option is selected, the user ID recorded in audit records is taken from the PROGRESS session, which is controlled through the SECURITY-POLICY object. On that object is a method SET-CLIENT( ), which allows setting the session-wide user ID by using a CLIENT-PRINCIPAL object.

Managing user IDs, see Chapter 4, " Identity Management."

Creating and using a CLIENT-PRINCIPAL object, see OpenEdge Development: Programming Interfaces .

Selecting the Use Application User Id for Auditing option, see the Data Administration Help.